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REMARKS 

Claims 1 5 21, 38 5 40, 47, 49, 51, 62 and 71 have been amended. 
Accordingly, Claims 1-11, 13, 17, 21-34, 38-43, 47-55, 57-60, 62-65 and 71-81 
are pending in the application. The reconsideration of the application is 
respectfully requested. 

Claim 62 was objected to because of an informality. Applicants have 
amended Claim 62 to remedy said informality. Thus, the objection to Claim 62 
should be withdrawn. 

Claims 21 and 62 were rejected under 35 U.S.C. Section 101. Claims 21 
and 62, as amended, are believed to be within the technological arts and to 
produce tangible results. Specifically, Claims 21 and 62 include a rules 
application process adapted to parse electronic billing data. Claims 21 and 62 
relate to computer technology by implementing the rules application process to 
extract and parse electronic billing data and a computer database for storing the 
transformed billing data. In addition, by parsing the electronic billing data, the 
invention of Claims 21 and 62 produces tangible results for storage in the 
computer database. In view of Applicants 1 amendments, the rejection of Claims 
21 and 62 under Section 101 should be withdrawn. 

Claims 1-11, 13, 17, 21-34, 38-43, 47-55, 57-60, 62-65 and 71-81 stand 
rejected under 35 U.S.C. Section 103(a) as unpatentable over Shutzer in view of 
Remington et al. For the sake of clarity, Claims 1-46 and 48-81 were rejected by 
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the Examiner. However, only Claims 1-11, 13, 17, 21-34, 38-43, 47-55, 57-60, 
62-65 and 71-81 are pending in the application. 

Further, the Examiner rejected Claims 30-33, which were renumbered as 
Claims 30-32, respectively, in Amendment C. 

The Examiner rejected Claim 34, which was renumbered as Claim 33 in 
Amendment C. 

The Examiner rejected Claims 41-43, 57, and 77, which were renumbered 
as Claims 40-42, 56, and 76, respectively, in Amendment C. 

The Examiner rejected Claims 48, 60, and 80, which were renumbered as 
Claims 47, 59, and 79, respectively, in Amendment C. 

Additionally, the Examiner failed to cite or provide any evidence for the 
anticipation, teaching, or suggestion of a translator and a common document tree 
which contains data and attributes which are mapped into nodes, as recited 
in independent Claims 38, 40, 47, 49, and 71. The Examiner also failed to 
cite or provide any evidence for the anticipation, teaching, or suggestion of a 
modularized input processing engine , as recited in independent Claims 51 and 71. 
Moreover, the Examiner failed to cite or provide any evidence for the 
anticipation, teaching, or suggestion of the step of modularizing a preprocessing of 
electronic billing data, as recited in independent Claim 62. 
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With respect to independent Claims 1, 21, 38, 40, 47, 49, 51, 62 and 71, the 
Examiner concedes that Schutzer does not teach the parsing/extracting 
functionality and cites the abstract, figs. 5, 7-9, column 3, line 35 to column 4, line 
65, and column 7, line 6 to column 8, line 50 of Remington et al. to cure this 
deficiency of Shutzer. The Examiner is entirely correct that Schutzer fails to teach 
the parsing/extractor functionality of Claims 1, 21, 38, 40, 47, 49, 51, 62 and 71. 
However, Applicants respectfully disagree with the Examiner's position, based on 
evidence presented herein, that Remington et al. teach the parsing/extractor 
functionality of the present invention. Furthermore, Applicants submit that neither 
Schutzer nor Remington et al. teach or suggest the common document model 
processing functionality of the present invention as recited in Claims 1, 38, 40, 47, 
49,51 and 71. 

Briefly, the present invention provides an adaptive electronic bill 
presentment and payment (EBPP) system which provides a common document 
model, allowing a plurality of billers to interface with the system of the present 
invention to cooperatively present and accept payment of bills. The present 
invention uses a rules application process to generate a translator that parses the 
toiler's data stream into a common document model tree . The data and their 
attributes are mapped into nodes that fit the common document model for storage 
in the database. The use of the common format document model and the 
universality of its structure allows the plurality of billers using the present 
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invention to maintain control , from a billing console functionality, over their 
billing data and how it is presented on any desired platform using any desired 
applications, formats and protocols. In other words, the present invention can 
accommodate individual data sets from, for example, both a first and second biller 
without mandating a particular template (for the billers to follow) for both billers. 
Essentially, Applicants 1 common model document processing functionality 
provides for a generic conversion process that is not confined to a particular 
industry, biller, or type of customer . Thus, the present invention provides for 
dynamic structural processing and conversion of a plurality of bill data types. 

Independent Claims 1, 21, 38, 40, 47, 49, 51, 62 and 71 recite an EBBP 
system or method which enables a plurality of billers to interface with each other 
to cooperatively present and accept payment of bills using a parsing (or extracting) 
functionality and a common document model processing functionality. More 
specifically, the parsing (or extracting) functionality of Claims 1, 21, 38, 40, 47, 
49, 51, 62 and 71 parses billing data using "rules of conversion" or "a rules 
application process" to provide dynamic structural processing and conversion for 
the common document model for use by the bill presentment and payment system. 
The rules of conversion of the present invention allows a wide variety of biller 
data types and formats to be operated on or parsed to fit a common document or 
data model which allow for the storage and processing of both data and its 
attributes. 
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As disclosed by Applicants, using "rules of conversion" allows the data to 
be put into a form and format where it is easier to generate and correlate the 
attributes for various data in a form that can be used by the common document 
model. Furthermore, by using a common document model format, the present 
invention provides a dynamic data structure . For example, not every biller data 
has the same information and data; each biller will have a subset of all data and 
attributes accommodated by the common document model and parsing/extractor 
functionality. Thus, the common document model and parsing functionality 
provides for a dynamic data structure which enables all billers to cooperatively 
present and accept payment of bills. 

Independent Claims 38, 40, 47, 49 and 71 distinguish over Schutzer and 
Remington et al. by reciting a parsing (or extractor) functionality using rules of 
conversion which is a rules application process allowing a user to generate a 
translator for parsing the billing data into a common document tree in which the 
common document tree contains data and attributes which are mapped into nodes 
which fit a common model document for storage. 

The creation of a translator for parsing data and attributes into a form that 
can be stored in a common format storage model allows the present invention to 
efficiently present the bill to the consumer, query the stored data, control how it 
will be presented (e.g., brand building); and use the stored data as a customer 
service tool (e.g., help desk) (see Applicants' Specification, page 10, lines 3-7). In 
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addition, each biller will have a subset of all data and attributes accommodated by 
the common document tree and parsing/extractor functionality because not every 
biller data has the same information and data. The parsing/extractor functionality 
provides a generic conversion process that is not confined to a particular industry, 
biller, or type of customer and accepts any subset of data from any biller. 

Schutzer discloses that the bill service provider converts the bill, along with 
enclosures, to a standard bill definition language (see Schutzer column 14, lines 
32-35). "The standard bill definition language is an extension of hypertext markup 
language/extended markup language that allows for combining templates with 
data and taking digital signatures" (see Schutzer, column 14, lines 35-38). In other 
words, Schutzer's standard definition format merely provides instructions for 
formatting the bills uniformly based on pre-determined templates . Therefore, as 
can be seen, Schutzer does not disclose a parsing functionality with a translator for 
parsing data into a common document tree with data and attributes . 

Applicants also respectfully traverse the Examiner's assertion that the 
common document model processing functionality is anticipated by the evidence 
cited by the Examiner (specifically, Schutzer figs. 1-7, and column 14, line 26 to 
column 15, line 2). Schutzer discloses that the bill service provider converts the 
bill, along with enclosures, to a standard bill definition language that allows for 
combining templates with data (see Schutzer column 14, lines 32-38). 

A significant difference between Schutzer and the present invention is that 
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Schutzer's standard definition format merely provides an instructional set of rules 
for formatting the bills uniformly based on pre-determined templates. On the 
other hand, Applicants' common document model processing functionality 
provides a generic conversion process that is "not confined to a particular industry, 
biller, or type of customer" (see Applicants' Specification, page 9, lines 3-5) and 
accepts any subset of data from any biller. Fundamentally, the common model 
processing allows the present invention to aggregate its fields of data to 
accommodate bills from any biller or type of customer (see Applicants' 
Specification, page 28, lines 9-17). For example, a first biller may require one 
particular subset of data while a second biller may require a similar subset data in 
additional to another subset of data that is substantially different from that of the 
first biller. Using the common model processing, the present invention can 
accommodate the individual data sets for both the first and second biller's without 
mandating a particular template for both billers. Therefore, billers retain 
autonomy on how they collect, group, display, and present their billing 
information. In short, Applicants' common document model processing 
functionality solves the problem associated with multiple billers having and 
requiring different information by accepting any subset of any data from any 
biller. 

Remington et al. do not cure the deficiencies of Schutzer. Remington et al. 
does not parse billing data from a plurality of billers corresponding a plurality of 
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biller data types and does not convert said plurality of biller data types in to a 
common document model. Remington et al. disclose an EBPP remittance system 
enabling a biller to create bill remittance information and allowing the customer to 
control the payment authorization. For example, the customer specifies the 
amount to be paid, either partial or full (see Remington et al., Abstract and Fig. 5). 
This same concept is disclosed at column 3, line 35 to column 4, line 65 of 
Remington et al. Then, the payment instruction and remittance information is 
transmitted to the biller in the toiler's prescribed format. In other words, 
Remington et al. discloses a single biller interface that allows a single biller to 
specify an individual format for presentment and payment of bills. The billers bill 
independently of each other and each creates their own, individualized format for 
presentment and payment of bills. Thus, Remington et al. do not disclose or 
suggest a parsing functionality and a common document model that allows a 
plurality of billers to cooperatively present and accept payment of bills. 

With respect to column 7, line 6 to column 8, line 50 of Remington et al., 
Remington et al. discloses a biller software implementing static data structure 
(emphasis added). More particularly, the biller computer generates a bill and 
remittance information according to a format created by the biller. However, this 
bill and remittance information, referred to as bill 128 by Remington et al., is 
"implemented simply as a static data structure which holds pertinent data related 
to the account and billing matters, as well as any remittance data desired by the 
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biller" (Remington et al., column 7, lines 61-64). Figs, 7-10 of Remington et al. 
shows details of the bill 128 (Fig. 5 shows partial and full payment options). 

As can be seen, the dynamic data structure, facilitated by the rules of 
conversion and provided by the common document model, as recited in Claims 1, 
21, 38, 40, 47, 49, 51, 62 and 71 and the static data structure of Remington et al. 
are total opposite of each other. Static data structure occupies the same amount of 
memory every time a program is run. In other words, static data structure is a data 
structure that is defined and allocated before execution, which therefore can not 
change size during execution. A dynamic data structure, on the other hand, is one 
that can grow or shrink as needed to contain the data the system wants stored. 
That is, the present invention can allocate new storage when its needed and discard 
that storage when it is done with it (not every biller data has the same information 
and data; each biller will have a subset of all data and attributes accommodated by 
the common document model). Hence, use of the common document model by 
the present invention allows accommodation of all biller data types. In short, the 
dynamic data structure provided for by the use common document model allows 
the data structure of the invention of Claims 1, 21, 38, 40, 47, 49, 51, 62 and 71 to 
grow or shrink (i.e., dynamic data structure) while Remington et al. teaches a bill 
format with static data structure. 

Furthermore, Applicants' invention is directed toward parsing incoming 
billing data to produce a common document model for processing. In contrast, 
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Remington et al. discloses that the biller computer generates a bill and remittance 
information according to a format created by the biller. In other words, 
Remington et al. is generating a bill while Applicants' invention is processing bills 
from a plurality of billers to transform the plurality of bill data types to a common 
document model wherein all biller data types are accepted. Thus, Applicants 
respectfully submit that the production of bills by a biller computer as disclosed by 
Remington et al. does not teach or suggest the conversion/transformation of biller 
data provided by a plurality of different billers with a plurality of data types (or 
fields). 

Thus, as can be seen, Remington et al. do not teach or suggest the parsing 
functionality, the translator and the common document tree. The EBPP remittance 
system of Remington et al. merely provides a static data structure that is limited to 
one biller f s customized format . Remington et al. do not "operate" on the biller 
data and do not parse the biller data into a common document tree with data and 
attributes mapped into nodes for a common model document. 

With regard to independent Claim 40, Claim 40 further distinguishes over 
Schutzer and Remington et al. by reciting "a biller interface coupled to said 
database adapted to allow said plurality of billers to identify market segments of 
said bill payers according to market rules and information retrieved from said 
database." The Examiner cites Schutzer, fig. 1-7, and column 14, line 26 to 
column 15, line 2 for Claim 40; however, the Schutzer drawings and text referred 
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to by the Examiner do not disclose a biller interface as recited in Claim 40. In 
fact, there is no mention of the billers being able to identify market segments of 
bill payers in the Schutzer patent. Remington et al. do not mention a biller 
interface as recited in Claim 40 either. The biller interface of Remington et al. 
allows billers to specify presentation and remittance information. Remington et al. 
do not disclose or suggest allowing the biller to identify market segments with the 
biller interface. 

Turning now to independent Claim 47, Claim 47 further distinguishes over 
Schutzer and Remington et al. by reciting "an agent interface coupled to said 
database adapted to allow a plurality of agents having agency relationships with 
said plurality of billers to communicate with said bill payers regarding bills." 
Once again, the Examiner cites Schutzer, figs, 1-7, column 14 line 26 to column 
15, line 2, which primarily disclose a bill service provider and not an agent 
interface as claimed. Remington et al. do not teach or suggest an "agent interface" 
either. Therefore, Applicants respectfully traverse the Examiner's assertion of 
anticipation as to an "agent interface" as recited in Claim 47.. 

With respect to independent Claim 49, Claim 49 further distinguishes over 
Schutzer by reciting "bill payer interactivity functionality adapted to detect and 
respond to communications from said bill payers by at least retrieving from said 
database information corresponding to said bill payers and presenting said 
information to said bill payers in a form requested by said bill payers; and biller 
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interactivity functionality adapted to detect and respond to communications from 
said plurality of billers by at least retrieving from said database information 
corresponding to said plurality of billers and presenting said information to said 
plurality of billers in a form requested by said plurality of billers." The Examiner 
again cites Schutzer, /?gs. 1-7, and column 14, line 26 to column 15, line 2, which 
discloses that the "bill can be sent or "pushed" when available or held and sent 
when requested, i.e., "pulled" (see Schutzer, column 14, lines 51-53). The 
reference, however, does not disclose that bills can be presented to bill payers in a 
form requested by the bill payers as claimed (emphasis added). In fact, Schutzer 
only "allows billers to personally customize and control the content and format of 
the bill presentment" (Schutzer, column 3, lines 8-9). 

Moreover, Applicants stress the feature of Claim 49 which presents 
information to bill payers "in a form requested by said bill payers" which feature is 
not disclosed by Schutzer. As disclosed by Applicants, "customers can pay ... in a 
manner where each bill is presented to the customer in a way that is specially 
tailored to the customer with graphics, advertising, and other information that has 
been demographically proven to connect with that particular customer" (see 
Applicants' Specification, page 12, lines 13-16). Succinctly, the present invention 
allows both billers and payers to customize and control the presentation of bills 
whereas Schutzer only allows billers to customize bills. Therefore, Applicants 
respectfully traverse the Examiner's assertion of anticipation as to the 
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"interactivity functionality" element recited in Claim 49. 

With regard to Remington et al., the biller interface of Remington et al. 
only allows the biller to customize the presentment while the customer customize 
the payment options. In contrast, Claim 49 allows both the biller and the customer 
to customize how bills are presented . 

Claim 51 further distinguishes over Schutzer and Remington et al. by 
reciting "a modularized input processing engine, said input processing engine 
adapted to preprocess billing data from a plurality of billers corresponding to a 
plurality of data types." The advantage of using a modularized processing engine 
is that this facilitates scalability and expandability. For example, if a new form of 
biller data is encountered or must be dealt with for transformation into a form and 
format, the modularized input processing engine of Claim 51 allows for the 
processing of the new biller data in a modular way (see Applicants' Specification, 
page 25, lines 17-19). There may be separate engines for each new form of data 
so that the output of each preprocessing engine is ready for processing by a rule- 
based parsing engine. In other words, because the preprocessing of biller data is 
modularized, a new input processing engine can easily be integrated to handle new 
data types. Therefore, Claim 51 is believed to be patentable for the reasons given 
above. 

Method Claim 62 further distinguishes over Schutzer and Remington et al. 
by reciting the step of "modularizing a preprocessing of billing data from a 
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plurality of billers corresponding to a plurality of data types." As previously 
discussed with respect to Claim 51, modularizing the preprocessing of biller data 
facilitates scalability and expandability without disrupting the present system 
configuration. Therefore, Claim 62 is believed to be patentable over Schutzer and 
Remington et al. for the reasons given above. 

Independent Claim 71 distinguishes over Schutzer and Remington et al. by 
reciting a modularized input processing engine, in a manner similar to Claim 5 1 . 
Therefore, Claim 71 is believed to be patentable over Schutzer and Remington et 
al. for the reasons given above. 

In view of the distinctions noted and the advantages attendant thereto, it is 
respectfully submitted that Schutzer and Remington et al., taken singly or 
combined, do not teach each and every aspect of the claimed invention of 
independent Claims 1, 21, 38, 40, 47, 49, 51, 62 and 71, either explicitly or 
impliedly. 

Claims 2-11, 13 and 17, which are dependent upon Claim 1, are believed to 
be patentable with the parent Claim 1. Claims 22-34, which are dependent upon 
Claim 21, are believed to be patentable with the parent Claim 21. Claims 39, 
which is dependent upon Claim 38, is believed to be patentable with the parent 
Claim 38. Claims 41-43, which are dependent upon Claim 40, are believed to be 
patentable with the parent Claim 40. Claims 48, which is dependent upon Claim 
47, is believed to be patentable with the parent Claim 47. Claims 50, which is 
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dependent upon Claim 49, is believed to be patentable with the parent Claim 49. 
Claims 52-55 and 57-60, which are dependent upon Claim 51, are believed to be 
patentable with the parent Claim 51. Claims 63-65, which are dependent upon 
Claim 62, are believed to be patentable with the parent Claim 62. Claims 72-81, 
which are dependent upon Claim 71, are believed to be patentable with the parent 


In summary, Claims 1-11, 13, 17, 21-34, 38-43, 47-55, 57-60, 62-65 and 
71-81 are believed to be allowable for the reasons given herein. Accordingly, 
these claims remain pending following entry of this Amendment, and are in 
condition for allowance at this time. As such, Applicants respectfully request 
entry of the present Amendment and reconsideration of the application, with an 
early and favorable decision being solicited. Should the Examiner believe that the 
prosecution of the application could be expedited, the Examiner is requested to 
call Applicants' undersigned representative at the number listed below. 


Customer No. 22922 

REINHART BOERNER VAN DEUREN s.c. 
Attn: Linda Gabriel, Docket Clerk 
1000 North Water Street 
Suite 2100 


Claim 71. 


Respectfully submitted, 


REINHART BOERNER VAN DEUREN s.c. 



Andrew T. Pham 
Reg. No. 54, 879 
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Milwaukee, WI 53202 
414-298-8160 
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